perm filename TIMING.MSG[TIM,LSP]2 blob
sn#570682 filedate 1981-03-10 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00050 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00008 00002 ∂27-Feb-81 1334 Deutsch at PARC-MAXC Re: Timings
C00010 00003 ∂27-Feb-81 1342 Dick Gabriel <RPG at SU-AI> Timings
C00012 00004 ∂27-Feb-81 1354 RPG Timings
C00014 00005 ∂27-Feb-81 1412 Bruce E. Edwards <BEE at MIT-AI> Re: timings
C00016 00006 ∂27-Feb-81 1427 Deutsch at PARC-MAXC Re: Timings
C00017 00007 ∂27-Feb-81 1502 Deutsch at PARC-MAXC Re: Timings
C00019 00008 ∂27-Feb-81 1533 Dick Gabriel <RPG at SU-AI> Timings
C00021 00009 ∂27-Feb-81 1616 Earl A. Killian <EAK at MIT-MC> Timings
C00022 00010 ∂27-Feb-81 1615 George J. Carrette <GJC at MIT-MC> timings
C00023 00011 ∂27-Feb-81 1655 David.Neves at CMU-10A Re: Timings
C00024 00012 ∂27-Feb-81 1658 David.Neves at CMU-10A Re: Timings
C00025 00013 ∂27-Feb-81 1710 CSVAX.fateman at Berkeley Timings
C00026 00014 ∂27-Feb-81 1719 CSVAX.fateman at Berkeley Timings
C00027 00015 ∂27-Feb-81 1730 CSVAX.fateman at Berkeley timings
C00029 00016 ∂27-Feb-81 1947 George J. Carrette <GJC at MIT-MC> Timings
C00031 00017 ∂27-Feb-81 2002 Howard I. Cannon <HIC at MIT-MC> Timings
C00032 00018 ∂27-Feb-81 2008 GYRO at MIT-ML (Scott W. Layson) Lisp timings
C00034 00019 ∂27-Feb-81 2048 PDL at MIT-DMS (P. David Lebling) [Re: Timings ]
C00035 00020 ∂27-Feb-81 2057 JONL at MIT-MC (Jon L White) Timings for LISP benchmarks, and reminder of a proposal by Deutsch
C00042 00021 ∂27-Feb-81 2117 Howard I. Cannon <HIC at MIT-MC> Timings for LISP benchmarks
C00043 00022 ∂27-Feb-81 2131 CWH at MIT-MC (Carl W. Hoffman) Timings
C00044 00023 ∂27-Feb-81 2201 CSVAX.fateman at Berkeley here's a test for you to look at/ distribute
C00053 00024 ∂27-Feb-81 2201 CSVAX.fateman at Berkeley Timings for LISP benchmarks, and reminder of a proposal by Deutsch
C00054 00025 ∂28-Feb-81 0916 NEDHUE at MIT-AI (Edmund M. Goodhue) Timings
C00055 00026 ∂28-Feb-81 1046 Barry Margolin <Margolin at MIT-Multics> Re: Timings
C00056 00027 ∂28-Feb-81 1109 Barry Margolin <Margolin at MIT-Multics> Re: Timings
C00057 00028 ∂28-Feb-81 1424 Deutsch at PARC-MAXC Re: Timings for LISP benchmarks, and reminder of a proposal by
C00058 00029 ∂28-Feb-81 1718 YONKE at BBND JONL's message concerning benchmarks
C00059 00030 ∂28-Feb-81 1818 CSVAX.fateman at Berkeley why I excluded GC times
C00061 00031 ∂28-Feb-81 2014 Guy.Steele at CMU-10A Re: Timings
C00063 00032 ∂28-Feb-81 2016 Scott.Fahlman at CMU-10A benchmarks
C00064 00033 ∂01-Mar-81 0826 PLATTS at WHARTON-10 ( Steve Platt) timing for lisp
C00065 00034 ∂01-Mar-81 1300 RJF at MIT-MC (Richard J. Fateman) more lisp mavens
C00066 00035 ∂02-Mar-81 0443 Robert H. Berman <RHB at MIT-MC> Timings
C00067 00036 ∂02-Mar-81 0543 Robert H. Berman <RHB at MIT-MC> Timings
C00068 00037 ∂02-Mar-81 0741 James E. O'Dell <JIM at MIT-MC> Timings
C00071 00038 ∂02-Mar-81 1006 Deutsch at PARC-MAXC Re: Timings
C00072 00039 ∂02-Mar-81 1312 Barry Margolin <Margolin at MIT-Multics> Re: Timings
C00073 00040 ∂02-Mar-81 1634 RPG Lisp Timings
C00078 00041 ∂03-Mar-81 1524 RPG Lisp Timing Mailing List
C00080 00042 Here's the first message, which you missed:
C00085 00043 ∂04-Mar-81 0449 Robert H. Berman <RHB at MIT-MC> Lisp Timing Mailing List
C00090 00044 ∂04-Mar-81 0957 Scott.Fahlman at CMU-10A Re: Translators
C00093 00045 ∂04-Mar-81 0959 CSVAX.char at Berkeley lisp benchmarking
C00096 00046 ∂04-Mar-81 1627 HEDRICK at RUTGERS sometime of possible interest
C00101 00047 ∂06-Mar-81 1301 HES at MIT-AI (Howard Shrobe) Methodology considerations:
C00103 00048 Subject: Lisp Timings Group
C00110 00049 ∂10-Mar-81 0727 correira at UTEXAS-11 lisp timings
C00112 00050 ∂03-Mar-81 2109 Barrow at SRI-KL (Harry Barrow ) Lisp Timings
C00115 ENDMK
C⊗;
∂27-Feb-81 1334 Deutsch at PARC-MAXC Re: Timings
Date: 27 Feb 1981 13:32 PST
From: Deutsch at PARC-MAXC
Subject: Re: Timings
In-reply-to: RPG's message of 27 Feb 1981 1319-PST
To: Dick Gabriel <RPG at SU-AI>
cc: info-lispm at MIT-AI
Your suggestion sounds great. What we need is someone to organize the process
just a little. Such a person would do something like the following:
1) Collect the names of volunteers or contact persons at each site, to send sample
programs to.
2) Collect the sample programs from each site, and disseminate them to the
volunteers or contacts at the other sites.
3) Collect the translated sample programs (in case there was controversy over
whether the translation was "trivial", for example, and for documentation and
historical purposes).
4) Collect the results of the timings run at each site, and disseminate them.
Would you like to volunteer?
∂27-Feb-81 1342 Dick Gabriel <RPG at SU-AI> Timings
Date: 27 Feb 1981 1319-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: Timings
To: deutsch at PARC-MAXC
CC: info-lispm at MIT-AI
Since everyone I know of is trying to make a decision about what
to do about Lisp computing in the next five years, perhaps we should
try to co-ordinate a test that will help everyone make a decision.
For instance, each center (PARC, MIT, Stanford, CMU, Berkeley,...)
can provide a program that is of interest to them (not too big, of course);
each test site will then provide someone to re-code (in a very trivial sense:
turning greaterp into >, adding declarations) those programs into reasonably
efficient code for their system. The authors will provide timing data and
timing points in their code.
Each center may have a few programs since they may have diverse
communities (SAIL and HPP at Stanford). I would be happy to volunteer to
test programs for SAIL MacLisp, which is a 10 version.
-rpg-
∂27-Feb-81 1354 RPG Timings
To: deutsch at PARC-MAXC
CC: RPG at SU-AI, info-lispm at MIT-AI
I will volunteer to co-ordinate the Lisp timing test. I plan to contact:
Deutsch/Masinter at Parc (InterLisp on MAXC, Dorado, Dolphin...)
RPG/ROD at SAIL (MacLisp on SAIL, TOPS-20, FOONLY F2)
VanMelle@SUMEX (InterLisp on TOPS-20)
Fateman at Berkeley (FranzLisp on VAX)
Hedrick at Rutgers (UCILISP on TOPS-10?)
Fahlman/Steele at CMU (SPICELISP on ?, MacLisp on CMU-10)
HIC at MIT (Lisp Machine)
JONL at MIT (MacLisp on ITS, NIL on VAX)
Westfold at SCI (InterLisp on F2)
Weyhrauch at SAIL (Ilisp on SAIL, LISP1.6 on SAIL)
If anyone has any suggestions about who else to contact or other Lisps
and/or machines to try, let me know soon.
-rpg-
∂27-Feb-81 1412 Bruce E. Edwards <BEE at MIT-AI> Re: timings
Date: 27 February 1981 16:32-EST
From: Bruce E. Edwards <BEE at MIT-AI>
Subject: Re: timings
To: CPR at MIT-EECS
cc: INFO-LISPM at MIT-AI, RWS at MIT-XX
As Peter Deutsch has pointed out this is a crummy benchmark, which was implemented
by relatively unenlighted programming on the CADR. I made it almost 50% faster
in 5 minutes, and the new numbers are much better. They could be made much better,
but basically people aren't interested in hacking uninteresting benchmarks. Things
like a natural language parser or an AI program is more what we are interested in.
There are some data points along this line, but I can't remember the exact numbers.
Hopefully RG has the numbers for the WOODS lunar program tucked away somewhere.
∂27-Feb-81 1427 Deutsch at PARC-MAXC Re: Timings
Date: 27 Feb 1981 14:26 PST
From: Deutsch at PARC-MAXC
Subject: Re: Timings
In-reply-to: RPG's message of 27 Feb 1981 1354-PST
To: Dick Gabriel <RPG at SU-AI>
Great! Perhaps we will finally throw some light into the murk of claims and
counter-claims about Lisp speeds that have been made for many years.
You might consider sending out some kind of announcement to LISP-FORUM
and/or LISP-DISCUSSION at MIT-AI as well -- I'm not sure everyone of interest
is on INFO-LISPM.
∂27-Feb-81 1502 Deutsch at PARC-MAXC Re: Timings
Date: 27 Feb 1981 13:32 PST
From: Deutsch at PARC-MAXC
Subject: Re: Timings
In-reply-to: RPG's message of 27 Feb 1981 1319-PST
To: Dick Gabriel <RPG at SU-AI>
cc: info-lispm at MIT-AI
Your suggestion sounds great. What we need is someone to organize the process
just a little. Such a person would do something like the following:
1) Collect the names of volunteers or contact persons at each site, to send sample
programs to.
2) Collect the sample programs from each site, and disseminate them to the
volunteers or contacts at the other sites.
3) Collect the translated sample programs (in case there was controversy over
whether the translation was "trivial", for example, and for documentation and
historical purposes).
4) Collect the results of the timings run at each site, and disseminate them.
Would you like to volunteer?
∂27-Feb-81 1533 Dick Gabriel <RPG at SU-AI> Timings
Date: 27 Feb 1981 1354-PST
From: Dick Gabriel <RPG at SU-AI>
Subject: Timings
To: deutsch at PARC-MAXC
CC: RPG at SU-AI, info-lispm at MIT-AI
I will volunteer to co-ordinate the Lisp timing test. I plan to contact:
Deutsch/Masinter at Parc (InterLisp on MAXC, Dorado, Dolphin...)
RPG/ROD at SAIL (MacLisp on SAIL, TOPS-20, FOONLY F2)
VanMelle@SUMEX (InterLisp on TOPS-20)
Fateman at Berkeley (FranzLisp on VAX)
Hedrick at Rutgers (UCILISP on TOPS-10?)
Fahlman/Steele at CMU (SPICELISP on ?, MacLisp on CMU-10)
HIC at MIT (Lisp Machine)
JONL at MIT (MacLisp on ITS, NIL on VAX)
Westfold at SCI (InterLisp on F2)
Weyhrauch at SAIL (Ilisp on SAIL, LISP1.6 on SAIL)
If anyone has any suggestions about who else to contact or other Lisps
and/or machines to try, let me know soon.
-rpg-
∂27-Feb-81 1616 Earl A. Killian <EAK at MIT-MC> Timings
Date: 27 February 1981 19:16-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject: Timings
To: RPG at SU-AI
I've got a queuing simulation program in MC:EAK;SIMUL > that
while it isn't at all typical of AI, uses an interesting mix of
list and numeric computation, and also runs for a fair time while
being not overly long. I'm not sure whether its useful to you,
but if it is, let me know.
∂27-Feb-81 1615 George J. Carrette <GJC at MIT-MC> timings
Date: 27 February 1981 17:35-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: timings
To: Deutsch at PARC-MAXC
cc: INFO-LISPM at MIT-MC, masinter at PARC-MAXC, guttag at MIT-XX,
RWS at MIT-XX
How about using Macsyma? It has some interesting programs in it,
and it has given the Lispmachine quite a work-out on some large
real problems (or did the Lispmachine give macsyma a work out?).
-gjc
∂27-Feb-81 1655 David.Neves at CMU-10A Re: Timings
Date: 27 February 1981 1954-EST (Friday)
From: David.Neves at CMU-10A
To: Dick Gabriel <RPG at SU-AI>
Subject: Re: Timings
In-Reply-To: Dick Gabriel's message of 27 Feb 81 16:54-EST
Message-Id: <27Feb81 195427 DN10@CMU-10A>
why not also try TLC lisp on a micro. ask jra@sail
also BBN's jerico might be relevant but i don't think they
have a lisp for it.
∂27-Feb-81 1658 David.Neves at CMU-10A Re: Timings
Date: 27 February 1981 1957-EST (Friday)
From: David.Neves at CMU-10A
To: Dick Gabriel <RPG at SU-AI>
Subject: Re: Timings
In-Reply-To: Dick Gabriel's message of 27 Feb 81 16:54-EST
Message-Id: <27Feb81 195751 DN10@CMU-10A>
p.s. also i believe people at BBN are trying to put Interlisp on
a Prime computer. If they do have a version up that would be a
another data point. i don't know who you would contact though.
∂27-Feb-81 1710 CSVAX.fateman at Berkeley Timings
Date: 27 Feb 1981 16:20:26-PST
From: CSVAX.fateman at Berkeley
To: RPG@SU-AI, deutsch@PARC-MAXC
Subject: Timings
Cc: info-lispm@mit-ai
add Griss@utah-20 (standard lisp on 10, b-1700, ...)
∂27-Feb-81 1719 CSVAX.fateman at Berkeley Timings
Date: 27 Feb 1981 16:22:33-PST
From: CSVAX.fateman at Berkeley
To: RPG@SU-AI, deutsch@PARC-MAXC
Subject: Timings
Cc: info-lispm@mit-ai
add Griss@utah-20 (standard lisp on 10, b-1700, ...)
∂27-Feb-81 1730 CSVAX.fateman at Berkeley timings
Date: 27 Feb 1981 16:43:27-PST
From: CSVAX.fateman at Berkeley
To: Deutsch@PARC-MAXC, GJC@MIT-MC
Subject: timings
Cc: INFO-LISPM@MIT-MC, RWS@MIT-XX, CSVAX.fateman@Berkeley, guttag@MIT-XX, masinter@PARC-MAXC
George: are you offering to put Macsyma up in Interlisp? We already
have some LM /KL-10/ VAX-11/780 benchmarks (KL-10 maclisp):
Vaxima and Lisp Machine timings for DEMO files
(fg genral, fg rats, gen demo, begin demo)
(garbage collection times excluded.) Times in seconds.
MC VAXIMA 128K lm 192K lm 256K lm VAXIMA Jul 80
4.119 17.250 43.333 19.183 16.483 15.750
2.639 7.016 55.916 16.416 13.950
3.141 10.850 231.516 94.933 58.166
4.251 16.700 306.350 125.666 90.716 12.400
(Berkeley CS.VAX 11/780 UNIX April 8, 1980, KL-10 MIT-MC ITS April 9, 1980.)
improvements due to expanding alike1 and a few odds and ends as macros;
also some improvements in the compiler.
∂27-Feb-81 1947 George J. Carrette <GJC at MIT-MC> Timings
Date: 27 February 1981 22:47-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: Timings
To: RPG at SU-AI
cc: deutsch at PARC-MAXC
I have a usefull benchmark which I just tried in Maclisp at MIT-MC
and on a LISPM. It is code which does line-drawing window-clipping
for arbitrary convex polygonal regions. This code is in actual use.
If you want to see it, it is on MIT-MC in
[MC:BLIS11;CLIP >]. (yes, I hack BLISS. (wow what a compiler!))
It is a nice example because it tests the speed of the FUNCALL dispatch.
The file is conditionalized to run in either LISPM or Maclisp, and
even includes the timing methods used. I would very much like it
if I could run the same (*exactly*) conditionalized source on
N different systems, that way I would have
(1) greater confidence
(2) an exact knowledged of how things are done differently on the
different systems. e.g. how much hair one has to go through to
declare things to the compiler.
-gjc
∂27-Feb-81 2002 Howard I. Cannon <HIC at MIT-MC> Timings
Date: 27 February 1981 23:02-EST
From: Howard I. Cannon <HIC at MIT-MC>
Subject: Timings
To: RPG at SU-AI
I'll be happy to do the timing tests.
--Howard
∂27-Feb-81 2008 GYRO at MIT-ML (Scott W. Layson) Lisp timings
Date: 27 FEB 1981 2306-EST
From: GYRO at MIT-ML (Scott W. Layson)
Subject: Lisp timings
To: rpg at SU-AI
CC: GYRO at MIT-ML, INFO- at MIT-ML, INFO-LISPM at MIT-ML
I know this is a little silly, but if you have any REALLY tiny
benchmarks (space-wise) I would like to try them out in TLC-Lisp
and muLisp, both running on a 64K Z-80. These Lisps don't page,
so the program and data have to fit in small real memory.
(Perhaps I should call them "Lisplets"?)
Incidentally, it seems to me that GC time should be included in
the times reported. Different systems generate garbage at
different rates and deal with it at different efficiencies,
and this shows up in the user-response time of the systems
(which is, after all, what we really want to know).
-- Scott Layson
---------------
∂27-Feb-81 2048 PDL at MIT-DMS (P. David Lebling) [Re: Timings ]
Date: 27 Feb 1981 2348-EST
From: PDL at MIT-DMS (P. David Lebling)
To: rpg at SU-AI
In-reply-to: Message of 27 Feb 81 at 1354 PST by RPG@SU-AI
Subject: [Re: Timings ]
Message-id: <[MIT-DMS].187847>
You should contact either CLR@MIT-XX or myself for Muddle.
Dave
∂27-Feb-81 2057 JONL at MIT-MC (Jon L White) Timings for LISP benchmarks, and reminder of a proposal by Deutsch
Date: 27 FEB 1981 2352-EST
From: JONL at MIT-MC (Jon L White)
Subject: Timings for LISP benchmarks, and reminder of a proposal by Deutsch
To: rpg at SU-AI
CC: LISP-DISCUSSION at MIT-MC, BEE at MIT-AI, JHL at MIT-AI
CC: CSVAX.fateman at BERKELEY, RWS at MIT-XX
I notice you sent your proposal to INFO-LISPM, and thought that the
LISP-DISCUSSION community might want to be aware of it too. (Deutsch and
Masinter are, I believe, on this list, as is Griss).
Date: 27 Feb 1981 1354-PST
From: Dick Gabriel <RPG at SU-AI>
I will volunteer to co-ordinate the Lisp timing test. I plan to contact:
Deutsch/Masinter at Parc (InterLisp on MAXC, Dorado, Dolphin...)
RPG/ROD at SAIL (MacLisp on SAIL, TOPS-20, FOONLY F2)
VanMelle@SUMEX (InterLisp on TOPS-20)
Fateman at Berkeley (FranzLisp on VAX)
Hedrick at Rutgers (UCILISP on TOPS-10?)
Fahlman/Steele at CMU (SPICELISP on ?, MacLisp on CMU-10)
HIC at MIT (Lisp Machine)
JONL at MIT (MacLisp on ITS, NIL on VAX)
Westfold at SCI (InterLisp on F2)
Weyhrauch at SAIL (Ilisp on SAIL, LISP1.6 on SAIL)
If anyone has any suggestions about who else to contact or other Lisps
and/or machines to try, let me know soon.
The contact for Rutgers-LISP should probably be JOSH@RUTGERS-10
(John Storrs Hall) who is actively extending the formerly-called UCILISP.
Fateman's login name is CSVAX.fateman@Berkeley unless there is some
smarts to his mailer that I don't know about.
Also, I'd like to suggest the following additions
GRISS@UTAH-20 for "STANDARD-LISP" on PDP10, IBM370, etc
John Allen (who knows where?) for his "Cromemco" lisp on Z80 etc
JHL@MIT-AI (Joachim Laubsch, from Stuttgart, West Germany) who might be
able to involve the European LISP community.
I'll also send a letter of these actions to Shigeki Goto of the Nippon
Telephone Co. in Tokyo, who generated some sort of flurry last fall with his
incrediblly-simple "benchmark" function TAK. Actually, TAK may be useful as
one part of a multi-foliate benchmark, since it specifically test timings
for (1) function-to-function interface, and (2) simple arithmetic of GREATERP
and SUB1. Some of Baskett's benchmarkings score heavily on the array
capabilities, for which FORTRAN compilers "come off smelling like a rose",
and even the fast-arithmetic of MacLISP savors like a garbage dump.
At the little "lisp discussion" held in Salt Lake City, December 1980,
(attendees partly co-incident with LISP-DISCUSSION mailing list), Peter
Deutsch made a suggestion which we all liked, but for which there
has been no subsequent action (to my knowledge). Basically, in order to
educate ourselves into the consequences of the differences between LISP
dialects, and to get some experience in converting "real" code, each
dialect community should nominate a representative piece of "useful code"
from its enviromment, and the groups responsible for the other
dialects would try to "transport" it into their own. Several benefits
should accrue:
(1) If the "representative" is some useful piece of the general environment,
say like the DEFMACRO "cache'ing" scheme of MacLISP/NIL, or the
Interlisp Masterscope, or whatever, then the "transportation" cost
will be repaid by having a useful new tool in the other dialects.
(2) We should accumulate a library of automatic conversion tools, or
at least of written reports on the problems involved.
(3) Each community may be affected in a way which (hopefully) will help
reduce the hard-core interdialect incompatibilities.
(Apologies to Deutsch for any garbling of the proposal content).
∂27-Feb-81 2117 Howard I. Cannon <HIC at MIT-MC> Timings for LISP benchmarks
Date: 28 February 1981 00:17-EST
From: Howard I. Cannon <HIC at MIT-MC>
Subject: Timings for LISP benchmarks
To: rpg at SU-AI, deutsch at PARC-MAXC
cc: Greenberg.Symbolics at MIT-MULTICS
I suggest Greenberg.Symbolics@MIT-MULTICS for Multics MacLisp.
∂27-Feb-81 2131 CWH at MIT-MC (Carl W. Hoffman) Timings
Date: 28 FEB 1981 0030-EST
From: CWH at MIT-MC (Carl W. Hoffman)
Subject: Timings
To: RPG at SU-AI
Date: 27 Feb 1981 1354-PST
From: Dick Gabriel <RPG at SU-AI>
If anyone has any suggestions about who else to contact or other Lisps
and/or machines to try, let me know soon.
-rpg-
You might also contact Richard Lamson or Bernie Greenberg for timings of
MacLisp on various Multics sites. Net addresses are "Lamson at MIT-Multics"
and "Greenberg at MIT-Multics".
∂27-Feb-81 2201 CSVAX.fateman at Berkeley here's a test for you to look at/ distribute
Date: 27 Feb 1981 21:26:56-PST
From: CSVAX.fateman at Berkeley
To: rpg@su-ai
Subject: here's a test for you to look at/ distribute
;; test from Berkeley based on polynomial arithmetic.
(declare (special ans coef f inc i k qq ss v *x*
*alpha *a* *b* *chk *l *p q* u* *var *y*))
(declare (localf pcoefadd pcplus pcplus1 pplus ptimes ptimes1
ptimes2 ptimes3 psimp pctimes pctimes1
pplus1))
;; Franz uses maclisp hackery here; you can rewrite lots of ways.
(defmacro pointergp (x y) `(> (get ,x 'order)(get ,y 'order)))
(defmacro pcoefp (e) `(atom ,e))
(defmacro pzerop (x) `(signp e ,x)) ;true for 0 or 0.0
(defmacro pzero () 0)
(defmacro cplus (x y) `(plus ,x ,y))
(defmacro ctimes (x y) `(times ,x ,y))
(defun pcoefadd (e c x) (cond ((pzerop c) x)
(t (cons e (cons c x)))))
(defun pcplus (c p) (cond ((pcoefp p) (cplus p c))
(t (psimp (car p) (pcplus1 c (cdr p))))))
(defun pcplus1 (c x)
(cond ((null x)
(cond ((pzerop c) nil) (t (cons 0 (cons c nil)))))
((pzerop (car x)) (pcoefadd 0 (pplus c (cadr x)) nil))
(t (cons (car x) (cons (cadr x) (pcplus1 c (cddr x)))))))
(defun pctimes (c p) (cond ((pcoefp p) (ctimes c p))
(t (psimp (car p) (pctimes1 c (cdr p))))))
(defun pctimes1 (c x)
(cond ((null x) nil)
(t (pcoefadd (car x)
(ptimes c (cadr x))
(pctimes1 c (cddr x))))))
(defun pplus (x y) (cond ((pcoefp x) (pcplus x y))
((pcoefp y) (pcplus y x))
((eq (car x) (car y))
(psimp (car x) (pplus1 (cdr y) (cdr x))))
((pointergp (car x) (car y))
(psimp (car x) (pcplus1 y (cdr x))))
(t (psimp (car y) (pcplus1 x (cdr y))))))
(defun pplus1 (x y)
(cond ((null x) y)
((null y) x)
((= (car x) (car y))
(pcoefadd (car x)
(pplus (cadr x) (cadr y))
(pplus1 (cddr x) (cddr y))))
((> (car x) (car y))
(cons (car x) (cons (cadr x) (pplus1 (cddr x) y))))
(t (cons (car y) (cons (cadr y) (pplus1 x (cddr y)))))))
(defun psimp (var x)
(cond ((null x) 0)
((atom x) x)
((zerop (car x)) (cadr x))
(t (cons var x))))
(defun ptimes (x y) (cond ((or (pzerop x) (pzerop y)) (pzero))
((pcoefp x) (pctimes x y))
((pcoefp y) (pctimes y x))
((eq (car x) (car y))
(psimp (car x) (ptimes1 (cdr x) (cdr y))))
((pointergp (car x) (car y))
(psimp (car x) (pctimes1 y (cdr x))))
(t (psimp (car y) (pctimes1 x (cdr y))))))
(defun ptimes1 (*x* y) (prog (u* v)
(setq v (setq u* (ptimes2 y)))
a (setq *x* (cddr *x*))
(cond ((null *x*) (return u*)))
(ptimes3 y)
(go a)))
(defun ptimes2 (y) (cond ((null y) nil)
(t (pcoefadd (plus (car *x*) (car y))
(ptimes (cadr *x*) (cadr y))
(ptimes2 (cddr y))))))
(defun ptimes3 (y)
(prog (e u c)
a1 (cond ((null y) (return nil)))
(setq e (+ (car *x*) (car y)))
(setq c (ptimes (cadr y) (cadr *x*) ))
(cond ((pzerop c) (setq y (cddr y)) (go a1))
((or (null v) (> e (car v)))
(setq u* (setq v (pplus1 u* (list e c))))
(setq y (cddr y)) (go a1))
((= e (car v))
(setq c (pplus c (cadr v)))
(cond ((pzerop c) (setq u* (setq v (pdiffer1 u* (list (car v) (cadr v))))))
(t (rplaca (cdr v) c)))
(setq y (cddr y))
(go a1)))
a (cond ((and (cddr v) (> (caddr v) e)) (setq v (cddr v)) (go a)))
(setq u (cdr v))
b (cond ((or (null (cdr u)) (< (cadr u) e))
(rplacd u (cons e (cons c (cdr u)))) (go e)))
(cond ((pzerop (setq c (pplus (caddr u) c))) (rplacd u (cdddr u)) (go d))
(t (rplaca (cddr u) c)))
e (setq u (cddr u))
d (setq y (cddr y))
(cond ((null y) (return nil)))
(setq e (+ (car *x*) (car y)))
(setq c (ptimes (cadr y) (cadr *x*)))
c (cond ((and (cdr u) (> (cadr u) e)) (setq u (cddr u)) (go c)))
(go b)))
!
(defun pexptsq (p n)
(do ((n (quotient n 2) (quotient n 2))
(s (cond ((oddp n) p) (t 1))))
((zerop n) s)
(setq p (ptimes p p))
(and (oddp n) (setq s (ptimes s p))) ))
(defun setup nil
(putprop 'x 1 'order)
(putprop 'y 2 'order)
(putprop 'z 3 'order)
(setq r (pplus '(x 1 1 0 1) (pplus '(y 1 1) '(z 1 1)))) ; r= x+y+z+1
(setq r2 (ptimes r 100000)) ;r2 = 100000*r
(setq r3 (ptimes r 1.0)); r3 = r with floating point coefficients
)
; time various computations of powers of polynomials, not counting
;printing but including gc time ; provide account of g.c. time.
; The following function uses (ptime) for process-time and is thus
; Franz-specific.
(defun bench (n)
(setq start (ptime)) ; Franz ticks, 60 per sec, 2nd number is GC
(pexptsq r n)
(setq res1 (ptime))
(pexptsq r2 n)
(setq res2 (ptime))
; this one requires bignums.
(pexptsq r3 n)
(setq res3 (ptime))
(list 'power= n (b1 start res1)(b1 res1 res2)(b1 res2 res3)))
(defun b1(x y)(mapcar '(lambda(r s)(quotient (- s r) 60.0)) x y))
;instructions:
; after loading, type (setup)
; then (bench 2) ; this should be pretty fast.
; then (bench 5)
; then (bench 10)
; then (bench 15)
;...
∂27-Feb-81 2201 CSVAX.fateman at Berkeley Timings for LISP benchmarks, and reminder of a proposal by Deutsch
Date: 27 Feb 1981 21:32:33-PST
From: CSVAX.fateman at Berkeley
To: JONL@MIT-MC, rpg@SU-AI
Subject: Timings for LISP benchmarks, and reminder of a proposal by Deutsch
Cc: BEE@MIT-AI, JHL@MIT-AI, LISP-DISCUSSION@MIT-MC
I have sent an entry (polynomial arithmetic system) to rpg@su-ai.
He can examine and redistribute.
( fateman@berkeley is equivalent to csvax.fateman@berkeley...)
∂28-Feb-81 0916 NEDHUE at MIT-AI (Edmund M. Goodhue) Timings
Date: 28 FEB 1981 1215-EST
From: NEDHUE at MIT-AI (Edmund M. Goodhue)
Subject: Timings
To: RPG at SU-AI
I suggest you add Jim Meehan at UCI (maintainer of UCI LISP) who can
run benchmarks on UCILISP and MLISP on both TOP-10 and TOPS-20. UCI
is not on the net but he can be reached via MEEHAN@MIT-AI.
Ned Goodhue
∂28-Feb-81 1046 Barry Margolin <Margolin at MIT-Multics> Re: Timings
Date: 28 February 1981 1343-est
From: Barry Margolin <Margolin at MIT-Multics>
Subject: Re: Timings
To: RPG at SU-AI
Cc: info-lispm at MIT-AI
I think you should also contact someone at MIT-Multics, where they run
MacLisp, although I'm not sure who you should contact.
∂28-Feb-81 1109 Barry Margolin <Margolin at MIT-Multics> Re: Timings
Date: 28 February 1981 1343-est
From: Barry Margolin <Margolin at MIT-Multics>
Subject: Re: Timings
To: RPG at SU-AI
Cc: info-lispm at MIT-AI
I think you should also contact someone at MIT-Multics, where they run
MacLisp, although I'm not sure who you should contact.
∂28-Feb-81 1424 Deutsch at PARC-MAXC Re: Timings for LISP benchmarks, and reminder of a proposal by
Date: 28 Feb 1981 14:23 PST
From: Deutsch at PARC-MAXC
Subject: Re: Timings for LISP benchmarks, and reminder of a proposal by
Deutsch
In-reply-to: JONL's message of 27 FEB 1981 2352-EST
To: rpg at SU-AI, LISP-DISCUSSION at MIT-MC, BEE at MIT-AI, JHL at MIT-AI,
CSVAX.fateman at BERKELEY, RWS at MIT-XX
JONL accurately represented the content of my proposal. The set of programs
being submitted for timing tests might indeed be a useful place to start.
∂28-Feb-81 1718 YONKE at BBND JONL's message concerning benchmarks
Date: 28 Feb 1981 2009-EST
Sender: YONKE at BBND
Subject: JONL's message concerning benchmarks
From: YONKE at BBND
To: RPG at SU-AI, Lisp-Discussion at MIT-MC
Message-ID: <[BBND]28-Feb-81 20:09:20.YONKE>
I'd like to add Interlisp on Jericho (our in-house machine).
Also, since BBN has several different flavors of DEC hardware
which run TOPS-20, I wouldn't mind supplying these different
timings and they would probably more informative than Kurt's
(VanMelle) from SUMEX.
Martin
∂28-Feb-81 1818 CSVAX.fateman at Berkeley why I excluded GC times
Date: 28 Feb 1981 17:15:23-PST
From: CSVAX.fateman at Berkeley
To: HES@MIT-AI
Subject: why I excluded GC times
Cc: CSVAX.fateman@Berkeley, info-lispm@mit-mc, lisp-discussion@mit-mc
including GC times makes for a very messy statistical situation.
GC time (or even if it happens at all) is dependent on the virtual
address space in use at the time, how much of the macsyma system
has been loaded (in the case of the KL-10), etc. I do not know
about the LM figures, since I am only reporting stuff sent to me,
but the KL-10 and the VAX typically spend 30% additional time in
GC, averaged over various "production" runs. Trading off GC time
for system paging time is a funny business, though I agree it
is important.
∂28-Feb-81 2014 Guy.Steele at CMU-10A Re: Timings
Date: 28 February 1981 2313-EST (Saturday)
From: Guy.Steele at CMU-10A
To: Dick Gabriel <RPG at SU-AI>
Subject: Re: Timings
In-Reply-To: Dick Gabriel's message of 27 Feb 81 16:54-EST
Message-Id: <28Feb81 231341 GS70@CMU-10A>
You may want to get in touch with the people at Utah (Standard LISP)
for various machines, and maybe John Allen (who has implementations
for micros, for low end of curve).
Also let me note that you are likely to get a great CACM article or
soemthing out of distilling all this stuff if you want; more power
to you. I'll coordinate running tests on SPice LISP, though that
may take some time to materialize.
--QW
xxx
--Q
∂28-Feb-81 2016 Scott.Fahlman at CMU-10A benchmarks
Date: 28 February 1981 2315-EST (Saturday)
From: Scott.Fahlman at CMU-10A
To: rpg at su-ai
Subject: benchmarks
Message-Id: <28Feb81 231549 SF50@CMU-10A>
Hi,
I just added my name to Lisp discussion recently and seem to have missed
something. Exactly what benchmarks are you running/getting people to
run? If there was a message that kicked all of this off, I would be
interested in seeing it.
We will be happy to add Spice Lisp on Perq benchmarks when the time comes,
but we won't be ready till summer.
-- Scott
∂01-Mar-81 0826 PLATTS at WHARTON-10 ( Steve Platt) timing for lisp
Date: 1 Mar 1981 (Sunday) 1124-EDT
From: PLATTS at WHARTON-10 ( Steve Platt)
Subject: timing for lisp
To: rpg at SU-AI
...if the systems are not *too* big, I'd like to try them on my micro
(Z80) lisp.... rough limits -- stack is a few hundred calls deep (I can
relink to change this if necessary), cell space is limited to roughly
10K cells. Most basic major lisp functions (a la maclisp, for the most
part) are implemented, others can be added.
-Steve
∂01-Mar-81 1300 RJF at MIT-MC (Richard J. Fateman) more lisp mavens
Date: 1 MAR 1981 1600-EST
From: RJF at MIT-MC (Richard J. Fateman)
Subject: more lisp mavens
To: rpg at SU-AI
Try boyer@sri-kl. They have an F2, and Boyer undoubtedly
could supply theorem-prover benchmark.
∂02-Mar-81 0443 Robert H. Berman <RHB at MIT-MC> Timings
Date: 2 March 1981 07:43-EST
From: Robert H. Berman <RHB at MIT-MC>
Subject: Timings
To: RPG at SU-AI
cc: deutsch at PARC-MAXC
Please add me to your timing test survey. I have several
suggestions of features that I would like to know about.
Thanks.
--Bob
∂02-Mar-81 0543 Robert H. Berman <RHB at MIT-MC> Timings
Date: 2 March 1981 08:43-EST
From: Robert H. Berman <RHB at MIT-MC>
Subject: Timings
To: RPG at SU-AI
cc: deutsch at PARC-MAXC
Please add me to your timing test survey. I have several
suggestions of features that I would like to know about.
Thanks.
-Bob
∂02-Mar-81 0741 James E. O'Dell <JIM at MIT-MC> Timings
Date: 2 March 1981 10:40-EST
From: James E. O'Dell <JIM at MIT-MC>
Subject: Timings
To: Margolin at MIT-MULTICS
cc: RPG at SU-AI
Date: 28 February 1981 1343-est
From: Barry Margolin <Margolin at MIT-Multics>
To: RPG at SU-AI
cc: info-lispm at MIT-AI
Re: Timings
I think you should also contact someone at MIT-Multics, where they run
MacLisp, although I'm not sure who you should contact.
If the timings don't take too long to work up I'd be glad to run the
Multics Lisp trials. As you might know we have a Macsyma running there
now, version 293. It typically runs at .6 of a MC. The tricky thing is that
on some BIG problems it runs as fast or faster than MC because of its
larger address space. It spends less of its time collecting garbage than
on MC. I feel that this is an important factor.
At least on of the timings should CONS up a storm. We have had problems
with address space on both the LISPM and on 10's. Some large Macsyma
probems use up all of the address space on the LISPM because we don't run
with the garbage collector. GC'ing on the LISPM slows things down a lot.
I also think that the LISPM is being unfairly compared because of its
single user nature. The numbers do not accurately reflect the responsiveness
observed by the user.
∂02-Mar-81 1006 Deutsch at PARC-MAXC Re: Timings
Date: 2 Mar 1981 10:06 PST
From: Deutsch at PARC-MAXC
Subject: Re: Timings
In-reply-to: RPG's message of 27 Feb 1981 1354-PST
To: Dick Gabriel <RPG at SU-AI>
cc: Masinter
Please take me off the list of people doing Lisp timings. Larry Masinter or
someone else at PARC who is actively working on Lisp (which I am not) is more
appropriate.
∂02-Mar-81 1312 Barry Margolin <Margolin at MIT-Multics> Re: Timings
Date: 2 March 1981 1610-est
From: Barry Margolin <Margolin at MIT-Multics>
Subject: Re: Timings
To: JIM at MIT-MC
Cc: RPG at SU-AI
Bernie Greenberg has already been volunteered to do the Multics MacLisp
timings, although I'm sure he won't mind your help, especially when it
gets to Macsyma timings.
∂02-Mar-81 1634 RPG Lisp Timings
To: info-lispm at MIT-AI, lisp-discussion at MIT-AI,
"#TIMING.MSG[TIM,LSP]" at SU-AI
As most of you know, there will be an attempt made to do a
series of Lisp timings in which various benchmarks submitted by the
Lisp community are tested on a variety of different Lisp systems.
Since there will need to be some translations done in order to run
these benchmarks in systems for which they were not intended, there
is the secondary (!) problem of learning what is really needed to do
these translations more readily in the future.
I will be co-ordinating this effort and will be distributing
the results when they are in. For this purpose I have set up 3
mailing lists at Stanford:
LISPTIMING the list of people interested in this topic
LISPTRANSLATORS, the list of people who have volunteered
to do the timing tests (and translations)
at the various sites
LISPSOURCES the list of people who will be supplying
benchmarks
You can MAIL to these entities at SAIL (e.g. MAIL
LISPTIMING@SAIL...) and thus avoid swamping the mailing lists we
have beenusing so far.
If you care to be on one of these lists, please send me
(rpg@sail) your login name and site exactly as your mailer will
understand it along with which list you wish to be on. If you are
supplying programs or talent, please let me know which Lisp, which
machine, and which OS you are representing.
In addition, a list of all messages pertaining to this
extravaganza will be on TIMING.MSG[TIM,LSP] at SAIL (you can
FTP from SAIL without logging in). In general, this area will
contain all of the information, programs, and results for this
project.
If you know of anyone who is not on the net and who may be
able to help, send me a message and a method for getting in touch
with him/her. Over the next few days I hope to establish some of the
methodological considerations (such as GC times) for the project.
Dick Gabriel (RPG@SAIL)
∂03-Mar-81 1524 RPG Lisp Timing Mailing List
To: "@LSPTIM.DIS[P,DOC]" at SU-AI
Welcome to the Lisp Timing mailing list. As you may have
already guessed, the scope of the Lisp Timing Evaluation project is
very large in scope, and if we are to make a contribution to the
undertanding of how to evaluate such an elusive thing as an entire
computing environment we will need to consider many methodological
issues. Since I am no expert on such evaluations I am going to require
a good deal of help, and so far more than 20 people have volunteered.
The problems we face are not just how to measure the performance
of these Lisp systems, but how to take a diverse set of benchmark
programs and get them to run on systems very different than those they
were written for.
I hope at the end of this project to be able to report not
only times for programs, but descriptions of systems, translation
problems, and a general guide to the world of Lisp computing.
The first substantive mailing will be a quick list of
methodological points we need to consider. This list is not complete,
but aims at the directions we need to go before actual timing runs
can be performed.
Thank you for your help in this project.
Dick Gabriel (RPG@SAIL)
Here's the first message, which you missed:
∂03-Mar-81 1616 RPG Methodology considerations:
To: "@LSPTIM.DIS[P,DOC]" at SU-AI
1. GC time is critical. Every timing should include CPU time
as measured by the CPU clock plus GC time. If GC time is not
accounted in the LISP, we should include a standard test, such
as a program that creates a large, standard structure (balanced
tree of some sort?) and then count CPU time on a forced GC, resulting
in a seconds/cell figure for each machine. Maybe we should do this
in addition to the benchmarks? [In fact, measuring GC time in a meaningful
way is que difficult due to different algorithms. Perhaps a range of
tree structures? Maybe not all algorithms are symmetric on car/cdr?]
2. Translating non-standard control structures can be a problem.
What about non-local goto's ala catch/throw? These can be simulated
with ERROR/ERRSET or with spaghetti hackery in InterLisp. These questions
should be addressed by having each translator propose various techniques
and having the source decide on which to use. Or maybe we should use
all such methods?
3. All non-LISP syntax must be pre-expanded (i.e. CLISP) to allow
the local system to optimize as appropriate.
4. Both interpreted and compiled code will be timed.
All code will have macros pre-expanded (at local sites?) so that
efficiencies due to incremental destructive expansion can be
eliminated.
5. Numeric code should have all types announced to the translators by the
sources so that optimizations can be made without deductions.
All other such information must be provided.
6. The size of such programs can be arbitrary, though translating
MACSYMA may take a while to do.
7. All tools developed to aid translation should be forwarded to
RPG so that they may be evaluated and distributed if appropriate.
8. Programs that are useful to a source but impossible (in a
practical sense) to translate should merit special attention to
decide if there is a useful feature involved.
9. (from GLR)
Timing various programs is a good idea, but the data will
be a little hard to extrapolate. Is anyone going to measure
parameters such as CONS rate, time to invoke a procedure,
and add times? [Not only that, but number CONSing and its
effect on numeric calculations should be measured as well. Here
RPG will appoint some experts (like JONL) to make up some
good numeric testing code to isolate implementational problems
with specific aspects of Lisp).
10. People should supply some estimate of the runtime and the results
of their benchmarks. Such things as 2 minutes of CPU on a KL running
TOPS-10 is OK, but for unfamiliar machines/Lisps this may not be good enough.
Try to aim at some estimate in terms of the number of CONSes or function
call depth.
11. Every candidate system should have a detailed description of that
description (CPU architecture, memory size, address size, paging algorithm...)
∂04-Mar-81 0449 Robert H. Berman <RHB at MIT-MC> Lisp Timing Mailing List
Date: 4 March 1981 07:48-EST
From: Robert H. Berman <RHB at MIT-MC>
Subject: Lisp Timing Mailing List
To: RPG at SU-AI
cc: " @LSPTIM.DIS[P,DOC]" at SU-AI
May I suggest the following as a benchmark for numerically orientated
problems: the time it takes to do a fast fourier transform of, say length
1024, of real or complex data.
I have been collecting over a period of 6 years timings for this
statistics on a wide range of machines (nearly 50) and compilers,
assemblers etc. Thus, this benchmark would be very helpful
in relating Lisp machine performance to many other architectures.
I have a class of problems that I run that use transform methods
for solving partial differential equations and performing
covolutions and smoothing. Hence my interest in ffts.
Several points to keep in mind about this benchmark:
1. On LM's there is a difference between small flonums and flonums.
Suppose it were done with macsyma's bigfloat package to allow
for extended precision.
2. Fast Fermat (Integer) Transforms are also helpful here. Integers
in the range 0 to 2↑20, say, can be as useful as small
flonums, but they use only integer arithmatic.
3. Power of 2 transforms, and their families, radix 2, rdaix 4+2,
radix 8+4+2, etc, can do some of their by shifting, rather than
dividing. But other bases, i.e. 96 instead of 64 or 128, can be more
efficient than doubling the transform length.
4. The internal data representation can make a difference. Local
variables on the stack of a subroutine are faster to reference than
arrays. I understand there is an architecturial limit of 64 stack
variables on LM's. Would it ever to be possible to change it? In a 4+2
algorithm, the fastest trasnform using stack variables only could then
be a 256 length transform, and then there would a degradation for
longer transforms that used array references.
5. I don't have a completely good feeling yet for all of the
subtleties and speedups available for microcoding a problem
vs writing in lisp, interpreting, compiling, or compiling
into microcode. When a segment of code is going to be used over and
over again, and the code isn't going to change, shouldn't it be
in microcode?
6. I can make several fft packages avaialable in lisp now. One is a
naive radix 2 butterfly algorithm, designed to be short to write and
implement in a hurry. The second is a radix 4+2 and radix 96 familiy
of transforms that were writen for a vector architecure like the Cray,
but translated nearly literally into lisp. Because the Cray encourages
temporary vectors, this radix 4+2 algorithm uses a lot of storage,
rather than transforms in place. I have not yet looked into the issues
I raised in 4.or 5., but these need attention as well.
-- Bob Berman (rhb@mc)
∂04-Mar-81 0957 Scott.Fahlman at CMU-10A Re: Translators
Date: 4 March 1981 1212-EST (Wednesday)
From: Scott.Fahlman at CMU-10A
To: Dick Gabriel <RPG at SU-AI>
Subject: Re: Translators
CC: guy.steele at CMU-10A
In-Reply-To: Dick Gabriel's message of 3 Mar 81 19:22-EST
Message-Id: <04Mar81 121256 SF50@CMU-10A>
Dick,
I notice in an earlier message that it was contemplated that a full set of
timings be done on CMU's modified TOPS-10 system running MACLISP. As a
point of information, all serious Maclisp work here has been moved to the
2060, now that we have one. I think that running benchmarks for an obsolete
and obviously brain-damaged system which nobody should ever again be forced to
use for anything seriosu would be a waste of time, and I am not likely to
want to devote any effort to it (although the task would be relatively small
if we get things already translated into legal Maclisp, since the differences
are few). I could devote some small amount of effort to benchmarking TOPS-20
maclisp, though there are other sites that have this as well and I would prefer
that they carry a good deal of the load on this.
We are willing, even eager, to get timings for Spice Lisp on the extended PERQ
(once we get an extended PERQ), but this effort will lag the others by 6 months
of so while we get our act together. I would prefer to save our translation
and measurement cycles for that task, since lots of places can check out a
Maclisp.
All of this looks fairly interesting. It may generate more heat than light,
but at least there will be some data to base the flames on, and the translation
aids should be a very useful side effect.
-- Scott
∂04-Mar-81 0959 CSVAX.char at Berkeley lisp benchmarking
Date: 4 Mar 1981 09:00:47-PST
From: CSVAX.char at Berkeley
To: rpg@sail
Subject: lisp benchmarking
Cc: anlams!boyle@Berkeley, CSVAX.char@Berkeley, CSVAX.fateman@Berkeley
Richard Fateman has informed me of the effort you're organizing to
compare Lisp systems. James Boyle (csvax.anlams!boyle@BERKELEY) and I
(csvax.anlams!char@BERKELEY) would like to be put on your mailing list
for lisp benchmarking. We have a program, part of a program
transformation system, which you may be interested in including in the
benchmarking. It currently runs on Franz, and on the IBM370 Lisp
available at Argonne. We could create a special version of the code
that predefines variables instead of reading their values off of files;
I/O was the only real problem I had in converting the program to Franz
this past fall. It is an interesting program in that it is a "real"
application of Lisp -- people have used the transformation system for
development of math software here at Argonne, as preprocessor to a
theorem prover, etc. It is not so interesting from the viewpoint of
exercising a lot of different Lisp features -- mainly list access and
creation, and CONDing. Jim Boyle estimates that an interesting
benchmark run would take 30-60 min. of Vax cpu time running under Franz
(interpreted). This might be too long for benchmarking, if testing
resources are expensive.
∂04-Mar-81 1627 HEDRICK at RUTGERS sometime of possible interest
Date: 4 Mar 1981 1919-EST
From: HEDRICK at RUTGERS
Subject: sometime of possible interest
To: rpg at SU-AI
I am not entirely clear what is going on with your lisp timings
mailing list. However you may possibly be interested in
looking at the file [rutgers]<hedrick>newlisp. You can FTP it
without logging in I think. I you have to log on over FTP,
specify user name ANONYMOUS and any password. This describes
the various tests I have done during design of ELISP, the new
extended addressing version of UCI Lisp for Tops-20. I think
ELISP will not have much in the way of innovations. It in
intended to be quite "classical". I.e. something that we know
how to do, and know that the results of will be useful for us.
It is Lisp 1.6/UCI Lisp constructed with Lisp machine technology
(to the extent we can do it on the 20, no CDR-coding, since that
requires micro code changes. But we do using a copying GC and
everything is done with typed pointers.) I expect the performance to be
similar to that of UCI Lisp, as the basic structures will be the same.
It will differ mostly because of completely different data
representations and GC methods. And because of extended addressing,
which on the 20 still has performance problems. NEWLISP refers to these
problems without explaining them. The main problem is in the design of
the hardware pager. This is the thing that maps virtual to physical
addresses. It should be associative memory, but is implemented by a
table. The net effect of the table is that the same entry is used for
pages 1000, 3000, 5000, 7000, etc. In fact, which line in the table is
used is determined by bits 774 of the page number (i.e. pages
1000,1001,1002, and 1003 are all stored in the same line). There is a
kludge to prevent odd numbered sections from interfering with even
numbered ones (The section number is bits 777000), which is why I listed
pages 1000, 3000,etc., and not 0, 2000, ... If you happen to be
unlucky, and have code in page 1000, a stack in page 3000, and
data in page 5000, your code can easily run a factor of 20 times
slower than it would otherwise. By carefully positioning various
blocks of data most of the problems can be prevented.
Please not that ELISP is intended to be a quick and safe implementation.
That means that I am not trying to get the last few percent of efficiency.
I am doing things in ways that I believe will not require much debugging
time, even at the price of speed. This is because I am a manager, and
don't have much time to write code or to support it after it is finished.
-------
∂06-Mar-81 1301 HES at MIT-AI (Howard Shrobe) Methodology considerations:
Date: 6 MAR 1981 1556-EST
From: HES at MIT-AI (Howard Shrobe)
Subject: Methodology considerations:
To: RPG at SU-AI
Re your comment about including GC time. I agree wholheartedly and have been
having a bit of disagreemnet with Fateman about same. IN addition I would
suggest trying to get statistics on how time shared machines degrade with load.
A lot of folks are trying to make estimates of personal versus time shared and
such choices can only be made if you know how many people can be serviced by a
VAX (KL-10, 2060, etc.) before performance drops off. Some discussion of this
issue would be useful to such folks.
howie Shrobe
Subject: Lisp Timings Group
To: rpg at SU-AI
cc: correira at UTEXAS-11
Hi. I've been involved with the maintenance/extensions of two lisps, UTLISP
(on CDC equipment) and UCILISP (Rutgers Lisp, etc). One of the things that I
did in our version of UCILISP that was missed by Lefaivre (and, hence, Meehan)
was to speed up the interpreter. (Lefaivre got a copy of my source shortly
before I made the speed ups.) It actually wound up being a few percent faster
than MACLISP (both on the same TOPS-10 machine). (I believe MACLISP source
code is close enough to make the same changes - this was very old/unchanged
code in the interpreter.)
Anyway, I'd like to volunteer running the tests on UCI Lisp on both a 2060
(TOPS-20) and a KI-10 (TOPS-10). I'm a little hesitant about committing
myself to too much work but it looks like you'll have several people running
UCI Lisp so maybe the work will be spread around. (I guess this means that
you should add me to your LISPTIMING and LISPTRANSLATORS lists.)
For easily transportable code, I'll run it on UTLISP but for any extensive
changes I'll pass. The current person who is in charge of that Lisp may send
you a separate note. I've tried to encourage him to do so. The UTLISP was
(at one time) judged by the Japanese surveyers to be the fastest interpreted
Lisp. (That is my recollection of the first survey that we were involved in,
sometime about the mid 70's?. I'm sure it was solely due to the speed of the
hardware.) It is not an elegant Lisp and has a lot of faults but is a pretty
fast interpreter. The compiler is a crock - when it works. It was someone's
masters thesis in the early 70's.
I strongly suggest that you run each of the various Lisps on different CPUs
whenever possible. There was a note out last fall that compared Interlisp,
Maclisp, and UCI Lisp. You may remember that I sent out a note that
complained that the timings for UCI Lisp were obviously on a different CPU
(probably a KI-10 compared to KL-10 or 2060).
I also suggest that while general purpose benchmarks may show a general
tendency, we should strive for timings of specific operations. Such things as
CONS (including GC time), variable binding, function calling, arithmetic,
property list manipulation, array manipulation, stack manipulation (I guess
that's in function calling/variable binding), tree traversing (CAR/CDR
manipulations), FUNARG hacking, COND evaluations, PROG and looping hacking,
etc. Personally my programs don't use much arithmetic so I don't think that's
too important but obviously some people do.
It would also be useful if people could supply timings of the machine the LISP
is run on. Such things as instruction fetch times and memory speed are
obviously important. This might be useful in comparing two Lisps on different
machines. (Exactly how does a CYBER-170/750 compare with a DEC-2060?)
I don't think that the programs need to be very big or long-running. They
just need to run long enough (10 seconds?) to minimize minor timing problems.
The important thing is that the various programs concentrate on one specific
area as much as possible. Of course, all this needs to be balanced by some
programs that have a general mix of operations.
Another possible test, which is not really a timing test, would be to give all
us hackers some particular programming project which would take on the order
of an hour to do. We would each do it in our own Lisp and report how long it
took us to do it (clock time) and how much resources we used (CPU time). It
might be also reasonable to report how we did it (eg, used EMACS or some other
editor to write/fix the code versus edit in Lisp itself, how many functions
(macros?), how much commenting, how transparent/hackish the code is, etc.) I
don't mean that this should be a programming contest but it might give some
idea what is involved in writing a program in each Lisp. This involves
composing, executing, debugging, and compiling. I feel this would be a truer
test of a LISP in a typical research situation if we could (hah!) discount the
various programmers skills/resources. (This suggestion should really stir
up some flames!!)
Mabry Tyson
(tyson@utexas-11)
-------
∂10-Mar-81 0727 correira at UTEXAS-11 lisp timings
Date: 10 Mar 1981 at 0916-CST
From: correira at UTEXAS-11
Subject: lisp timings
To: rpg at su-ai
cc: atp.tyson at utexas-20
If anyone is interested, I would be willing to do the work to run the
timing programs for UTLISP Version 5.0. This is the latest version of
UTLISP, containing code to drag the dialect into the 20th Century of
LISP interpreters. It has been my experience in the past that
most people shrug UTLISP off with a "oh, that's the one with the extra
pointer field" comment, but I think it is a pretty good LISP now and should be
included in the timings effort. However, the compiler is still a complete
crock (although I am working on a new one, it won't be ready for at least
6 months), so I will pass on doing compiler timings. Please add my name to
the LISPTIMING and LISPTRANSLATORS mailing lists.
Alfred Correira
UTEXAS-11
-------
∂03-Mar-81 2109 Barrow at SRI-KL (Harry Barrow ) Lisp Timings
Date: 3 Mar 1981 1727-PST
From: Barrow at SRI-KL (Harry Barrow )
Subject: Lisp Timings
To: rpg at SU-AI
I would certainly like to be on your list of recipients of
LISP timing information. Please add BARROW@SRI-AI to your list.
Did you know that Forrest BAskett has made some comparative timings
of one particular program (cpu-intensive) on several machines, in
several languages? In particular, LISP was used on DEC 2060, KL-10,
KA-10, and MIT CADR machines (CADR came out comparable with a KA-10,
but about 50% better if using compiled microcode).
What machines do you plan to use? I would be very interested to
see how Dolphins, Dorados, and Lisp machines compare...
Harry.
-------
Yes, I know of Baskett's study. There is at least one other Lisp
study, by Takeuchi in Japan.
So far we have the following Lisp systems with volunteers to
do the timings etc:
Interlisp on MAX, Dolphin, Dorado
MacLisp on SAIL
InterLisp on SUMEX
UCILISP on Rutgers
SpiceLisp on PERQ
Lisp Machine (Symbolics, CADR)
Maclisp on AI, MC, NIL on VAX, NIL on S1 (if available)
InterLisp on F2
Standard Lisp on TOPS-10, B-1700, LISP370
TLC-lisp and muLisp on z-80
Muddle on DMS
Rutgers Lisp
Lisp Machine
UCILISP and MLISP on TOPS-10, TOPS-20
Jericho InterLisp
some Z80 LISP
Multics Maclisp
Cromemco Lisp on Z80
Franz Lisp on VAX UNIX